REMARKS 



Claims 1-35 are pending. Claims 1-32 were rejected. Claims 1, 2, 7, 9 to 12, 14, 25, 28 
and 32 are currently amended. Claims 33 to 35 have been added. The title was objected to and 
amended according to Examiner's suggestion. Applicants request reconsideration and allowance 
for the following reasons. 

Objection to the Specification: 

The specification was objected to because "[t]he title of the invention is not descriptive." 
The Office Action ("Action") required the inclusion of some mention of "backward 
compatibility." An amendment to the title reflecting this requirement is found above, and 
Applicant respectfully requests the objection to the title be withdrawn. 

35 U.S.C. $ 112 (indefinite) rejection: 

Claims 1 and 25 were rejected as indefinite, stating that it is unclear what "assembling" 
entails, and what a "snapshot" contains. Although these claims have been amended, Applicant 
has retained use of the term "snapshot" because the claim is definite. Applicant, therefore, 
requests reconsideration and withdrawal of the rejection. 

The concept of a "snapshot" is well known in computer fields. Typically, it describes the 
state of some component within a computer system at a specific point in time. Here, claims 1 
and 25 refer to snapshots of an interface. The specification, at paragraphs 20-24, provides ample 
description of these snapshots and the uses for them. This claim terminology would be well 
understood by one of skill in the art and, therefore, the indefiniteness rejection should be 
withdrawn. 

Claims 1, 7, and 28 were rejected as indefinite for claiming the feature of "rating each 
detected difference according to a backward compatibility metric." Again, this terminology 
would be well understood by one of skill in the art. In mathematics, the term metric refers to a 
function that describes the distances between pairs of points in a space. The rejected claims 
indicate that such a function is to be applied to backward compatibility measurements based on 
ratings of detected differences between the snapshots. This language is clear. Accordingly, the 
indefiniteness rejections to claims 1, 7 and 28 should be withdrawn. 
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Claims 1, 7, 25, and 28 were rejected as indefinite for claiming the feature of 
"determining an overall backward compatibility ... based on the difference ratings." The 
"difference ratings" are not indefinite for the reasons stated above. "[Determining an overall 
backward compatibility" would be well understood by one of skill in the art. The term "overall" 
would be understood to refer to the backward compatibility of the snapshot as a whole, instead of 
each detected difference, as discussed above. The term "backward compatibility" is well 
understood in the art, and generally relates to determining if something is interchangeable with 
an older version of that same thing. Accordingly, the indefiniteness rejections to claims 1, 7, 25 
and 28 should be withdrawn. 

Claims 1, 7, 25, and 28 were rejected as indefinite for claiming the feature of "issuing an 
alert containing the overall backward compatibility." The Action states, "[t]his limitation is not 
clearly understood because it is not clear why the alert is issued. . ." The term "overall backward 
compatibility" is definite for the reasons stated above. One skilled in the art would understand 
what is meant by "issuing an alert." The Action asks "why" and "when an alert is issued. The 
why and when may represent example embodiments, but are not necessary for one skilled in the 
art to understand what is meant by "issue an alert" where that alert contains the "overall 
backward compatibility" discussed previously. 

All other claim rejections based on indefinite language are essentially the same as those 
discussed above and those rejections should be withdrawn for at least the same reasons. 

35 U.S.C. § 103 rejection of Claims 1, and 2 to 6: 

Claim 1 was rejected as obvious in view of U.S. Patent No. 6,986,132 Bl ("Schwab") 
and in further view of U.S. Patent No. 7,069,474 B2 ("Atallah"). Claim 1 has been amended to 
refer to a software update monitoring method for a multi-author design environment including 
"issuing an alert message to registered authors of the software design environment." None of the 
cited art teaches or suggests this subject matter. Schwab's disclosure refers only to comparing 
programs by their APIs and to indicating a verification error if incompatible. Schwab col. 13, 
line 66 to col. 14, line 1 1. In Schwab's system, "program modules are optionally verified by a 
card manufacturer, a card issuer and an applet or library provider." Schwab col. 26, lines 22-23. 
Schwab has no disclosure corresponding to alert messages that are sent to registered authors of 
the software design environment. 
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Additionally, neither Schwab nor Atallah teaches "rating each detected difference 

[between snapshots] according to a backward compatibility metric." The Office Action asserts 

that the rating of each binary file in Atallah corresponds to this element. Applicants respectfully 

disagree. Atallah states only that the: 

risk assessment system 210 examines the output of the appcert 
application to determine whether the binary file invokes any 
unsupported symbols[, or] ... invokes any libraries that have a 
known problem[ or behavioral change, or] ... performs any static 
links to unchanged system libraries ... [and] then a record is 
generated indicating that the binary file has failed the binary 
compatibility test[, or] presents a high [or low] risk of failing the 
binary compatibility test... The process ... may be repeated for 
each binary file received in the input file to generate a series of 
records indicating the likelihood that each binary file ... will suffer 
a binary compatibility failure with the ABI it was tested against. 

Atallah, col. 6, line 55 to col. 7, line 9. In Atallah's system, the compatibility of a binary file is 

given a rating. Only one rating is given, and the rating is only an overall rating for the binary. 

For example, Atallah's program will "determine whether the binary file invokes any unsupported 

symbols." See Atallah col. 6, line 21 to 22. Whether the binary invokes one unsupported 

symbol or a million unsupported symbols, the binary is only given one rating of "failed." This 

does not teach or suggest "rating each detected difference." Rating each detected difference is a 

non-obvious feature of a non-obvious "method for monitoring updates to software interfaces in a 

multi-author software design environment." 

Claims 2 to 6 ultimately depend from claim 1 and are allowable for at least the same 

reasons. 

35 U.S.C. $ 103 rejection of Claims 7 and 8 to 11: 

Claim 7 was rejected as obvious in view of Schwab and in further view of Atallah. Claim 
7 was rejected for reasons essentially similar to previously discussed claims. Claim 7, however, 
recites "rating each detected difference" and "issuing an alert message ... to registered authors 
of the software design environment"; and for at least the reasons discussed above, is allowable 
over the cited art. Claims 8 to 1 1 depend from claim 7 and are allowable for at least the same 
reasons. 

Additionally, Claim 8 claims "alert messages [which] include[] a summary of each 
detected difference." Atallah states only: 
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The process ... may be repeated for each binary file received in the 
input file to generate a series of records indicating the likelihood 
that each binary file ... will suffer a binary compatibility failure 
with the ABI it was tested against... It will be appreciated that the 
binary file may be tested against multiple ABIs. This information 
may be formatted as a report and transmitted to the end user. 

Atallah, col. 7, lines 5-16. A report of the rated compatibility of each tested ABI does not teach 

a report of the rated compatibility of every element of a snapshot that had a detected difference. 

For the additional reason that Atallah fails to teach or suggest the "each detected difference" 

error report, claim 8 is allowable. 

35 U.S.C. $ 102(e) rejection of Claims 12 and 13: 

Claims 12 and 13 were rejected as being anticipated by Schwab. Claim 12, as amended, 
is allowable for similar reasons as those above. Schwab does not teach "issuing an alert to 
registered authors of the software design environment." Schwab discloses only comparing 
programs by their APIs and if incompatible "a verification error is indicated," but not "issuing an 
alert to registered authors. . ." For at least this reasons claims 12 and 13 are allowable. 

35 U.S.C. § 103 rejection of Claims 14. and 15 to 24: 

Claim 14 was rejected over Schwab. Claim 14 recites several elements that distinguish 
Schwab, including: 

rating each detected difference according to a backward compatibility metric; and 
issuing an alert to registered authors of the software design environment when at least 
one of the detected differences indicates the first software interface is not backward 
compatible with respect to the second software interface. 

Schwab does not teach or suggest this subject matter. 

As discussed in prior claims, Schwab does not teach or suggest "rating each detected 
difference." Schwab teaches in col. 25, line 2, "verification using API definition files of 
backward compatible revisions. . ." However, Schwab makes no mention of "rating each 
detected difference," only of verifying compatibility of two files. As mentioned earlier, Schwab 
may indicate the result of the verification, but does not teach "issuing an alert to registered 
authors of the software design environment." For at least these reasons Claim 14 is allowable. 
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Claims 15 to 24 ultimately depend from claim 14 and should be allowable for at least the 
reasons given above. 

Additionally, regarding the specific rejection to claim 16, the Action cites Atallah as 
teaching that "[a]fter the end user has registered, one or more of the utilities that constitute the 
risk assessment system may be made available for downloading (step 320) to the subscriber over 
the internet..." (Atallah, col. 5, lines 40-52). Registering with a website to download the 
assessment tool does not teach or suggest "assigning a user to [a] snapshot" and "issuing the alert 
message to the user." Atallah states that the "information may be formatted as a report and 
transmitted to the end user over a suitable communication link..." (Atallah, col. 7, lines 11-13). 
However, this does not teach or suggest "assigning a user to the first snapshot," and for this 
additional reason claim 16 is allowable. 

35 U.S.C. $ 103 rejection of Claims 25 to 32: 

Claims 25, 28 and 32 were rejected for similar reasons as previously discussed claims. 
All three claims claim issuing and alert to registered authors of the software design environment, 
and are allowable for at least the reasons discussed above regarding that feature. Additionally, 
claims 28 and 32 claim rating each detected difference and are allowable for at least the reasons 
discussed above regarding that feature. Since claims 26 and 27 depend on claim 25, and since 
claims 29 to 3 1 depend on claim 28 they are allowable for at least the reasons mentioned above. 



14 



CONCLUSION 

In view of all of the above, it is believed that any objections and rejections have been 
obviated, and that claims 1 to 35 are allowable. It is therefore respectfully requested that the 
objection and rejection be withdrawn, and that the present application issue as early as possible. 

If for any reason the Examiner believes that contact with Applicant's attorney would 
advance the prosecution of this application, he or she is invited to contact the undersigned at the 
number given below. 

Respectfully submitted, 

Date: December 10, 2007 /Linda Shudv Lecomte/ 

Linda Shudy Lecomte 
Reg. No. 47,084 

KENYON & KENYON LLP 
1500 K Street, NW, Suite 700 
Washington, DC 20005-1257 
(202) 220-4200 telephone 
(202) 220-4201 facsimile 
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